deal with git's CFLR nonsense once again

Work around git hash-object --stdin-paths's odd stripping of carriage
return from the end of the line (some windows infection), avoiding crashing
when the repo contains a filename ending in a carriage return.

diff --git a/CHANGELOG b/CHANGELOG
index 77fea4eb73a19675dc28fcaa96510c81431a7bcf..fece6c4def94cf52b0f1ebd856f5e45a2966beac 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,11 @@
+git-annex (10.20241203) UNRELEASED; urgency=medium
+
+  * Work around git hash-object --stdin-paths's odd stripping of carriage
+    return from the end of the line (some windows infection), avoiding
+    crashing when the repo contains a filename ending in a carriage return.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 02 Dec 2024 13:41:31 -0400
+
 git-annex (10.20241202) upstream; urgency=medium
 
   * add: Consistently treat files in a dotdir as dotfiles, even

diff --git a/Git/HashObject.hs b/Git/HashObject.hs
index 1474c5709d89a8b4513b8b986fe44dc5bf0eb169..620c09514129c4fdfee5fd3d01bef4ba4409df86 100644 (file)
--- a/Git/HashObject.hs
+++ b/Git/HashObject.hs
@@ -48,13 +48,17 @@ hashFile hdl@(HashObjectHandle h _ _) file = do
        -- So, make the filename absolute, which will work now
        -- and also if git's behavior later changes.
        file' <- absPath file
-       if newline `S.elem` file'
+       if newline `S.elem` file' || carriagereturn `S.elem` file
                then hashFile' hdl file
                else CoProcess.query h (send file') receive
   where
        send file' to = S8.hPutStrLn to file'
        receive from = getSha "hash-object" $ S8.hGetLine from
        newline = fromIntegral (ord '\n')
+       -- git strips carriage return from the end of a line, out of some
+       -- misplaced desire to support windows, so also use the newline
+       -- fallback for those.
+       carriagereturn = fromIntegral (ord '\r')
 
 {- Runs git hash-object once per call, rather than using a running
  - one, so is slower. But, is able to handle newlines in the filepath,

diff --git a/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__.mdwn b/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__.mdwn
index 71a559f2ebcfde351bf9da8147ec64075ef0117e..e0df1225bc241406d915d133f40157971f875191 100644 (file)
--- a/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__.mdwn
+++ b/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__.mdwn
@@ -73,3 +73,5 @@ It succeeds at moving the large `test2` file into `.git/annex/objects` and symli
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Yes! :) It's helped me manage an unruly mess of files, backups, and backups of backups.
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__/comment_1_0a3132101d9cc48afa55d467d1c3e12a._comment b/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__/comment_1_0a3132101d9cc48afa55d467d1c3e12a._comment
new file mode 100644 (file)
index 0000000..982073e
--- /dev/null
+++ b/doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__/comment_1_0a3132101d9cc48afa55d467d1c3e12a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-02T16:41:07Z"
+ content="""
+Reproduced on linux. This is pretty surprising since `\r` is not a
+particularly special character.
+
+Adding any file not matching largefiles with '\r` in its name will trigger
+it, the rest is not needed.
+
+`git hash-object --stdin-paths` is what is failing.
+
+       printf '/home/joey/tmp/tr/example/Icon3\r\n' | git hash-object --stdin-paths
+       fatal: could not open '/home/joey/tmp/tr/example/Icon3' for reading: No such file or directory
+
+So, this is a misbehavior in git, which prevents passing a filename ending
+in '\r' into --stdin-paths here. Probably git is removing DOS style CRLF
+when it should not. I have reported this (and several related bugs) to the
+git mailing list so it might get fixed.
+
+`git cat-file --batch` also has this behavior, and git-annex already works
+around it by treating "\r" the same as "\n" and avoiding using the batch
+interface for it. (It could use -z, which avoids the problem, but older
+git's don't support that option.)
+
+I've made git-annex treat "\r" as special for git hash-object as well.
+"""]]